Why

We got pretty close to having TypedDicts for river-python inputs before, but had to roll back due to a protocol mismatch.

Trying again, and also adding some tests to confirm that at the very least the Pydantic models can decode was was encoded by the TypedDict encoders. It's not a perfect science, but it should be good enough to start building more confidence as we make additional progress.

The reason for "janky" tests

There's a bit of a chicken-and-egg situation when trying to test code generation at runtime.

We have three options:

• write pytest handlers where each invocation runs the codegen with a temp target (like the shell script does here), writes a static file for each text into that directory, then executes a new python into that directory. The challenge with this is that it would suck to write or maintain.
• write pytest handlers which runs the codegen with unique module name targets (like gen1, gen2, gen3, one for each codegen run necessary) and carefully juggle the imports to make sure we don't try to import something that's not there yet. This might be the best option, but I'm not convinced about the ergonomics at the moment. It might be OK though, with highly targeted .gitignore's.
• maintain a bespoke test runner, optimize for writing and maintaining these tests, and just acknowledge that we are doing something obscure and difficult.

I definitely wrote the tests here in a way that would give some coverage and also provide confidence, while intentionally deferring the above decision so we can keep making progress. in the meantime.

What changed

• Added some janky tests for comparing the encoding of both models
• Fixed many bugs in the TypedDict codegen and encoders

Test plan

$ bash scripts/parity.sh
Using /tmp/river-codegen-parity.bAZ
Starting...
Verified